Do not enforce 0-99 priority rule on system events#94
Merged
pavelsavara merged 1 commit intoJun 22, 2026
Merged
Conversation
System events (WinEvent, BattleEndedEvent, SkippedTurnEvent, RoundEndedEvent, etc.) have a fixed priority of 100, which is outside the 0-99 range allowed for robot-defined events. When something stamps such an event with its default priority, Event.setPriorityHidden() clamped it to 99 and printed misleading 'SYSTEM: Priority must be between 0 and 99' / 'Priority for robocode.WinEvent will be 99' warnings to the robot console. Fix setPriorityHidden() to return early for critical (system) events, leaving their priority untouched and emitting no warning. Also make EventManager.setEventPriority() return after warning a robot that it may not change a system event's priority, so the change is genuinely ignored. isCriticalEvent() is package-private and robocode.* classes cannot be defined by the robot class loader, so robots cannot override it to abuse this path.
flemming-n-larsen
approved these changes
Jun 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
System events (
WinEvent,BattleEndedEvent,SkippedTurnEvent,RoundEndedEvent,DeathEvent) have a fixed priority of100, which is outside the0-99range allowed for robot-defined events. When the engine (or tooling that reconstructs events) stamps such an event with its per-class default priority,Event.setPriorityHidden()clamped it to 99 and printed misleading noise to the robot console:Fix
Event.setPriorityHidden()now returns early for critical (system) events, leaving their priority untouched and emitting no warning. System events already overridegetPriority()to return their fixed value, so the unset field is never consulted.EventManager.setEventPriority()now returns after warning a robot that it may not change a system event's priority, so the request is genuinely ignored (previously it fell through and applied/clamped the value).Security
isCriticalEvent()is package-private torobocodeand the robot class loader refuses to define anyrobocode.*class from robot bytes (delegating to the trusted parent loader regardless of the security flag), so robots cannot override it to abuse this path.